Electronic file security management platform

ABSTRACT

According to some embodiments, an electronic file security management platform may receive a request from a user to access a first electronic file associated with a first application, such as a word processing document. A security characteristic associated with the user may be determined, and an encrypted version of the first electronic file may be decrypted in accordance with the security characteristic. The electronic file security management platform may then arrange for the user to access the first electronic file via the first application such that: (i) a first portion of the first electronic file is available to the user based on a first security requirement associated with the first portion and the security characteristic, and (ii) a second portion of the first electronic file is not available to the user based on a second security requirement associated with the second portion and the security characteristic.

FIELD

Some embodiments relate to systems and methods associated withelectronic files. More specifically, some embodiments are directed tosystems and methods to provide an electronic file security managementplatform.

BACKGROUND

An enterprise typically stores large amounts of information inelectronic files. For example, a company might store word processingdocuments, financial spreadsheets, and business presentations in arepository that may be accessed by employees. Note, however, that insome situations the enterprise might want to limit access to theseelectronic files. For example, not all employees should be allowed toview a document that lists every employee's home address and yearlysalary. To limit access to this type of information, a securityrequirement may be associated with some or all of the electronic files.For example, FIG. 1 illustrates an example 100 including a firstelectronic file 110 and a second electronic file 120. The firstelectronic file 110 is associated with a first security requirement(e.g., a first password) while the second electronic file 120 isassociated with a second security requirement (e.g., a second password).Thus, employees in a human resources department might be given thesecond password and, as a result, only those employees might be able toaccess the second electronic file 120.

In many cases, an electronic file may be associated with multipleportions. For example, the electronic files 110, 120 in FIG. 1 eachcontain a first portion and a second portion. Moreover, an enterprisemight be interested in limiting access to certain portions while stillallowing access to other portions (e.g., a school might want to letstudents access one portion of an electronic file that lists homeworkassignments while preventing access to another portion that lists thetest scores of all students). Providing a security requirementassociated with an entire electronic file, however, does not providesuch a capability.

Accordingly, methods and mechanisms to efficiently, accurately, and/orautomatically limit access to portions of electronic files may beprovided in accordance with some embodiments described herein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example including two electronic files.

FIG. 2 illustrates an example including two electronic files accordingto some embodiments.

FIG. 3 is a block diagram of a system associated with electronic filesin accordance with some embodiments.

FIG. 4 is a flow diagram of a process in accordance with someembodiments.

FIG. 5 is a block diagram of a system associated with electronic filesin accordance with some embodiments.

FIG. 6 illustrates streaming information in accordance with someembodiments.

FIG. 7 is a block diagram of an apparatus according to some embodiments.

FIG. 8 illustrates a portion of a tabular security management databasethat might be stored in accordance with some embodiments.

FIG. 9 illustrates a graphical user interface display that might beprovided to a file creator in accordance with some embodiments.

FIG. 10 illustrates a display that might be provided to a file viewer inaccordance with some embodiments.

DETAILED DESCRIPTION

An enterprise may stores information in electronic files, such as wordprocessing documents, financial spreadsheets, and business presentationsin a repository that may be accessed by employees. Moreover, eachelectronic file might include a number of different portions. Forexample, FIG. 2 illustrates an example 200 including a first electronicfile 210 and a second electronic file 220, each including a firstportion and a second portion.

In many cases, an enterprise might be interested in limiting access tocertain portions while still allowing access to other portions (e.g., abusiness might want to let employees access one portion of an electronicfile that lists broad business goals while preventing access to anotherportion that lists specific companies that the businesses is thinking ofpurchasing to meet those goals). Accordingly, methods and mechanisms toefficiently, accurately, and/or automatically limit access to portionsof electronic files may be provided in accordance with some embodimentsdescribed herein. In particular, as illustrated in FIG. 2, a firstportion of the first electronic file 210 is associated with a firstsecurity requirement while a second portion of the first electronic file210 is associated with a second security electronic file. Similarly, afirst portion of the second electronic file 220 is associated with afirst security requirement while a second portion of the secondelectronic file 220 is associated with a second security electronicfile. Thus, if an employee is given a password representing the firstsecurity requirement, he or she would be able to access the firstportion of both files 210, 220 without being able to access the secondportions.

FIG. 3 is a block diagram of such a system 300 according to someembodiments. The system 300 includes an electronic file securitymanagement platform 350 coupled to one or more databases or data storescontaining a file repository 330. By way of example only, the electronicfile security management platform 350 might be associated with anEnterprise Resource Planning (ERP) server, a business services gateway,a HyperText Transfer Protocol (HTTP) server, and/or an Advanced BusinessApplication Programming (ABAP) server. According to some embodiments,the electronic file security management platform 350 may also beconnected to various user management systems. For example, an SAP® HANAuser management system, MICROSOFT® WINDOWS user management system, etc.might provide permissions of the portions from a user in such systems.

According to some embodiments, the electronic file security managementplatform 350 may directly communicate with one or more remote userdevices 310 via the Internet. According to other embodiments, a gatewaymay be provided between the electronic file security management platform350 and the user devices 310. The user devices 310 may include one ormore processors to receive electronic files and/or to executeapplications and/or components (e.g., a plug-in that is integrated to asmartphone).

Note that FIG. 3 represents a logical architecture for the system 300according to some embodiments, and actual implementations may includemore or different components arranged in other manners. Moreover, eachsystem described herein may be implemented by any number of devices incommunication via any number of other public and/or private networks.Two or more of devices may be located remote from one another and maycommunicate with one another via any known manner of network(s) and/or adedicated connection. Further, each device may comprise any number ofhardware and/or software elements suitable to provide the functionsdescribed herein as well as any other functions. Other topologies may beused in conjunction with other embodiments.

Any of the devices illustrated in FIG. 3, including the electronic filesecurity management platform 350 and user devices 310 may exchangeinformation via any communication network which may be one or more of aLocal Area Network (LAN), a Metropolitan Area Network (MAN), a Wide AreaNetwork (WAN), a proprietary network, a Public Switched TelephoneNetwork (PSTN), a Wireless Application Protocol (WAP) network, aBluetooth network, a wireless LAN network, and/or an Internet Protocol(IP) network such as the Internet, an intranet, or an extranet. Notethat any devices described herein may communicate via one or more suchcommunication networks.

All systems and processes discussed herein may be embodied in programcode stored on one or more computer-readable media. Such media mayinclude, for example, a floppy disk, a CD-ROM, a DVD-ROM, magnetic tape,OR solid state Random Access Memory (RAM) or Read Only Memory (ROM)storage units. Embodiments are therefore not limited to any specificcombination of hardware and software.

FIG. 4 is a flow diagram of a process 400 that might be associated withthe electronic file security management platform 350 and/or user devices310 of FIG. 3 according to some embodiments. Note that all processesdescribed herein may be executed by any combination of hardware and/orsoftware. The processes may be embodied in program code stored on atangible medium and executable by a computer to provide the functionsdescribed herein. Further note that the flow charts described herein donot imply a fixed order to the steps, and embodiments of the presentinvention may be practiced in any order that is practicable.

At S410, a request from a user to access a first “electronic file”associated with a first application may be received at an electronicfile security management platform. As used herein, the phrase“electronic file” might refer to, for example, a word processingdocument, a spreadsheet file, an image file, an audio file, a videofile, an electronic mail file, streaming information a text file, an XMLfile, a source code file, and/or any combination of these types ofinformation. By way of example, an employee might indicate to theelectronic file security management platform that he or she wishes toopen a word processing document associated with a legal contract.

At S420, a “security characteristic” associated with the user may bedetermined. As used herein, the phrase “security characteristic” mightrefer to, for example, a user identifier, a user credential (e.g., apassword or security certificate), a user role within an organization, auser age, social network information, a user gender, a user'sresidential area, a rank within an organization, a user device, userpreferences, past behavioral patterns, and/or any combination of thesetypes of information. For example, it might be determined that a userrequesting access to word processing document associated with a legalcontract is an engineer but not an attorney.

At S430, an encrypted version of the first electronic file may bedecrypted in accordance with the security characteristic. For example, apassword, security certificate, a PGP key, and/or any other type ofinformation might be used to decrypt the electronic file.

At S440, it may be arranged, via the electronic file security managementplatform, for the user to access the first electronic file via the firstapplication. In particular, a first portion of the first electronic filemay be available to the user based on a first security requirementassociated with the first portion and the security characteristic. Note,however, that a second portion of the first electronic file may not beavailable to the user based on a second security requirement associatedwith the second portion and the security characteristic. For example, anengineer might be allowed to view and modify certain portions of a legalcontract (e.g., associated with target due dates) while not beingallowed to view and/or modify other portions (e.g., associated withlegal definitions or disclaimers). As used herein, a user's access to aportion of an electronic file might be associated with, for example,viewing the portion, deleting the portion, changing the portion,creating a new portion, and/or altering a security requirementassociated with a portion (e.g., changing who is allowed to view thatportion).

FIG. 5 is a block diagram of a system 500 associated with electronicfiles in accordance with some embodiments. As with FIG. 3, users maycommunicate with an electronic file security management platform 550 viauser devices (e.g., PCs, laptop computers, smartphones, etc.) to createor access electronic files stored in a file repository 530 via anapplication 520. For example, a user might want to access a wordprocessing document stored in the file repository 530 via a wordprocessing application. According to some embodiments, the electronicfile security management platform 550 interfaces with the application520 via one or more Application Programming Interfaces (APIs) andplug-in components 540. Note that both the application 520 and plug-in540 may exchange information with an operating system 560, such as aclipboard component of the operating system 560.

In some cases, a creator of an electronic file may define a securityrequirement for a document portion. For example, the author of adocument might highlight a particular portion and indicate to theelectronic file security management platform 550 that only managersshould be allowed to change that portion. According to some embodiments,an electronic file security management platform 550 might automaticallyassign a security requirement to a portion based on content detected inthat portion. For example, the electronic file security managementplatform 550 might detect that employee salary information was “cut andpasted” into a table and, as a result, automatically limit viewing ofthat table to employees who work in the company's human resourcesdepartment. Note that according to some embodiments, such informationmay be obtained from metadata (either configured by a user, providedwith the platform 550, received from an online source, or accumulated bymonitoring work that provides characteristics of a portion). Accordingto some embodiments, a metadata repository 570 (located locally, via aserver, or via the web) may build up and maintain such informationindentifying electronic information and its required security leveland/or correct characterization.

According to some embodiments, an automatic notification may begenerated when content is detected that conflicts with securityrequirements (e.g., in accordance with a rule stored in the metadatarepository 570). Moreover, a final version of an electronic file may beautomatically verified and security requirements may be associated toportions of the final version in accordance with information in themetadata repository 570.

According to other embodiments, an electronic file security managementplatform might automatically assign a security requirement to a portionbased on a creator of the portion. For example, changes to a paragraphwritten by someone in a legal department might only be allowed to bechanged by other employees in the legal department. Note that any changeto an electronic file might result in the file being re-encrypted tocreate a re-encrypted version that will replace the prior encryptedversion of the electronic file.

Thus, different portions of a single electronic file within therepository 530 may be edited and/or viewed as appropriate in accordancewith a context of a specific user (or the role of that user within anenterprise). According to some embodiments, a user accesses theelectronic file security management platform 550 to edit a file in therepository 530. According to some embodiments, access via theapplication 520 is based on logging credentials to enable protection ofthe file and only allowing the editor to open the file. Note thatfurther editing of the file might not be owned only by the file creatorbut may instead be performed by others (e.g., in accordance with theirroles and specific user identities). According to some embodiments, theuser selects the type of file to edit according to the availablesupported applications 520 (e.g., having appropriate plug-ins 540 foreach application 520). Note that plug-in 540 allows for the running ofthe application 520 from the user context and directs it to save fileson a specific directory or to follow a file path in which the currentfile is being edited. Such an approach doesn't need to be limited to aparticular file system and can be in the same way in any repository.

The user may now edit the file and at any point might specify that aspecific portion should only be accessed by a specific user or aspecific role. During editing, the user may also start a new portionthat is characterized with specific metadata and/or attributesqualifying the section to be limited to a specific authorized user orspecific roles. According to some embodiments, a final version of adocument may be reviewed and, according to specific metadatacharacterizing information, different portions may be assigned thecorrect security, authentication, and/or role adaptation according tothe attributes and the metadata characterizing the information (e.g.,payroll information might be characterized as something that onlymanagers are allowed to see as personal and protected information). Thefinal version of a file might be associated with the highest securitylevel that was set within the file.

The plug-in 540 might use direct access to the application 520 based onan enhancement provided by the application or any open API provided bythe application 520 (such as via macros or XML). The plug-in 540 mayalso use the platform of the operation system 560 to allow access toapplication 520 using current capabilities or enhanced capabilities madespecifically to support the electronic file security management platform550. Note that the platform 550 might also determine information aboutthe current user from other applications, such as an SAP® HANA system.For example, consider a record with a field from type binary which is aword document. In this case, the system 500 may enable portion 1 in thedocument to be seen by user having a role of “viewer” in an SAP® HANAsystem. According to some embodiments, the binary content may be alreadyencrypted and plug-in 540 may be used to view the encrypted content.

According to some embodiments, when the user is done editing the filevia the application 520, the file is then encrypted and saved in suchway that only the electronic file security management platform 550 canopen it with the specific (corresponding) plug-in 540. For specificapplications 520 that allow proper APIs and collaboration for the properplug-in 540, the file might be provided directly under electronic filesecurity management platform 550 context. For example, there are manyapplications 540 that allow exporting files via “print” capabilities. Inthe same way, a “save” or “save as” feature may be altered by acorresponding plug-in 540 to be saved under electronic file securitymanagement platform 550 context.

A user who wants to read/view a file edited via the electronic filesecurity management platform 550 might need to use the electronic filesecurity management platform 550 to view that file. The user may first,for example, login with his or her credentials and be identified by anappropriate user identification and/or role. If a user does not have theapplication 520 installed, the plug-in 540 might still provide a view ofthe file. Note that the exposed parts of the file provided to the usermight represent only those portions that were specified for the specificuser or for the user's corresponding role and authorization were definedeither directly by an author or editor of the file or according tometadata characterizing the content. If a specific user wants to re-edita file, he or she might only be allowed to do so only in those portionsthat are available to him or her for editing. After re-editing, the filemay then be encrypted again and saved.

To specify edited portions of a file, such as a document, for access bya specific user or role, the plugin 540 may operate to allow instantaccess to available options (e.g., by pressing a “hot key” and rightclicking on a selected paragraph). According to some embodiments, a usermay configure in advance a set of users and their roles such as byforming groups based on a user management environment in anorganization, based on friends from social networks, or based on anyknown way of user and role management that allows integration to thesystem 500 (e.g., associated with a user management engine) and/or asimple extraction and import of information via the plug-in 540.

A user or organization might configure a set of rules, attributes and/ormetadata for different types of content and/or define, categorize,and/or characterize types of information to be available section duringfile editing. According to some embodiments, a pre-determined or defaultset of rules may be provided. Some or all of this information might bestored, for example, in the metadata repository 570.

During editing, a user may click a hot key to open an electronic filesecurity management platform 550 menu and indicate a current start pointto be viewable only by a specific user (or specific role) and anassociated end of the portion. In the same way, a user might define acharacteristic of current content and provide corresponding metadata forit according to his or her own roles and authorizations. According tosome embodiments, there may be an automatic process that reviews a fileand, configured rules, attributes and pre-defined definitions may letthe electronic file security management platform 550 designate sectionsas appropriate (e.g., all pages watermarked as “Top Secret” might bedesigned as only being viewable by employees having such a securityclearance).

In addition to documents and spreadsheets, some embodiments may beassociated with streaming files. For example, FIG. 6 illustratesstreaming information 610 in accordance with some embodiments. Inparticular, a video stream file may contain content rated to specificage. This may be used to censor inappropriate content on the flyaccording to specific classifications of the content. According to someembodiment, such security requirements may be stored as metadata in anencrypted version of an electronic file. For example, first and thirdportions 610, 630 of the streaming information 600 might only beviewable by those who are at least eighteen years old (and younger usersmight only be presented with a blank screen during those portions 610,630 or the information might simply be skipped) while a second portion620 might be viewable by everyone.

Note that the architectures described with respect to FIGS. 3 and 5 areprovided only as an example, and any other type of apparatus might beprovided instead. For example FIG. 7 is a block diagram overview of onesuch apparatus 700 according to some embodiments. The apparatus 700 maybe, for example, associated with an employee device and/or a businessserver. The apparatus 700 comprises a processor 710, such as one or morecommercially available Central Processing Units (CPUs) in the form ofone-chip microprocessors, coupled to a communication device 720configured to communicate via a communication network (not shown in FIG.7). The communication device 720 may be used, for example, as an inputpath to receive employee inputs and/or business system data. Theapparatus 700 further includes an input device 740 (e.g., a mouse and/orkeyboard to enter security requirements) and an output device 750 (e.g.,a computer monitor to display business information reports that a useris authorized to view).

The processor 710 communicates with a storage device 730. The storagedevice 730 may comprise any appropriate information storage device,including combinations of magnetic storage devices (e.g., a hard diskdrive), optical storage devices, and/or semiconductor memory devices.The storage device 730 stores a program 712 and/or business dataplatform 714 for controlling the processor 710. The processor 710performs instructions of the programs 712, 714, and thereby operates inaccordance with any of the embodiments described herein. For example,the processor 710 may receive a request from a user to access a firstelectronic file associated with a first application, such as a wordprocessing document. A security characteristic associated with the usermay be determined by processor 710, and an encrypted version of thefirst electronic file may be decrypted in accordance with the securitycharacteristic. The processor 710 may then arrange for the user toaccess the first electronic file via the first application such that:(i) a first portion of the first electronic file is available to theuser based on a first security requirement associated with the firstportion and the security characteristic, and (ii) a second portion ofthe first electronic file is not available to the user based on a secondsecurity requirement associated with the second portion and the securitycharacteristic.

The programs 712, 714 may be stored in a compressed, uncompiled and/orencrypted format. The programs 712, 714 may furthermore include otherprogram elements, such as an operating system, a database managementsystem, and/or device drivers used by the processor 710 to interfacewith peripheral devices.

As used herein, information may be “received” by or “transmitted” to,for example: (i) the apparatus 700 from another device; or (ii) asoftware application or module within the apparatus 700 from anothersoftware application, module, or any other source.

In some embodiments (such as shown in FIG. 7), the storage device 730stores a file repository database 760, a security management database800, and/or a user credentials database 770 (e.g., including employeeuser names and passwords). An example of a security management database800 that may be used in connection with the apparatus 700 will now bedescribed in detail with respect to FIG. 8. Note that the databasedescribed herein is only an example, and additional and/or differentinformation may be stored therein. Moreover, various databases might besplit or combined in accordance with any of the embodiments describedherein.

Referring to FIG. 8, a table is shown that represents the securitymanagement database 800 that may be stored at the apparatus 700according to some embodiments. The table may include, for example,entries identifying portions of electronic files associated with anenterprise. The table may also define fields 802, 804, 806, 808, 810 foreach of the entries. The fields 802, 804, 806, 808, 810 may, accordingto some embodiments, specify: a file identifier 802, a portionidentifier 804, a security requirement 806, a user's securitycharacteristics 808, and an access indication 810. The information inthe security management database 800 may be created and updated, forexample, based on data received from file creators, editors, and/or theuser.

The file identifier 802 may be, for example, a unique alphanumeric codeidentifying an electronic file and the portion identifier 804 identifiesa sub-set of the information in the file. For example, as illustrated bythe first two entries in FIG. 8, the file identifier F_101 is associatedwith two portions: P_101 and P_102. The security requirement 806 mightindicate a condition, rule, or logic that defines who can access aparticular portion. For example, portion P_102 of file F_101 can beaccessed by any user who is an employee of enterprise while portionP_101 of that file can only be accessed by user's who work in the humanresources department. Note that portion P_101 of file F_102 may beindependent of P_101 of file F_101 (and have different securityrequirements 806). The user's security characteristics 808 defineinformation about the user (e.g., the user's role within the enterpriseand age) and the access indication 810 might indicate whether or not theuser is allowed to access that particular portion of the file.

Note that the security management database 800 may further supportinteraction with a user management system. For example, a shareddocument accessed via an SAP® HANA application might have portionsaccessible in accordance with HANA user management. When the samedocument is accessed via a portal other portions might be available.Note that a management platform may be used by other applications toretrieve the encrypted electronic file. As a result, user credentialsand authorizations in the system (e.g., either HANA, Portal, Sharepoint,etc.) can be transferred and used by the management platform to provideappropriate content to a user.

Thus, some embodiments may establish methods and mechanisms toefficiently, accurately, and/or automatically limit access to portionsof electronic files. Moreover, embodiments may let users view and/oredit files in accordance with their particular roles within anorganization.

The following illustrates various additional embodiments and do notconstitute a definition of all possible embodiments, and those skilledin the art will understand that the present invention is applicable tomany other embodiments. Further, although the following embodiments arebriefly described for clarity, those skilled in the art will understandhow to make any changes, if necessary, to the above-described apparatusand methods to accommodate these and other embodiments and applications.

Although embodiments have been described with respect to businesssystems, note that embodiments may be associated with other types ofenterprise data. For example, financial, governmental, and/or medicalinformation may be processed in accordance with any of the embodimentsdescribed herein.

Embodiments have been described herein solely for the purpose ofillustration. Persons skilled in the art will recognize from thisdescription that embodiments are not limited to those described, but maybe practiced with modifications and alterations limited only by thespirit and scope of the appended claims.

What is claimed is:
 1. A computer implemented method of facilitatingaccess to electronic files via a plurality of applications, comprising:receiving, at an electronic file security management platform, a requestfrom a user to access a first electronic file associated with a firstapplication the electronic file comprising a first portion and a secondportion; automatically determining, via a processor device, a firstsecurity requirement associated with the first portion, the determiningof the first security requirement comprising: automatically detectingadditional data of a particular type that has been added to the firstportion of the electronic file, automatically determining, in responseto the detection, a category of users that can view the added data, andautomatically limiting access of the first portion of the electronicfile to the category of users based upon the added content detected inthe first portion, the first security requirement stored in an encryptedversion of the first electronic file; determining a securitycharacteristic associated with the user; decrypting the encryptedversion of the first electronic file in accordance with the securitycharacteristic and the security requirement associated with the firstportion; and arranging, via the electronic file security managementplatform, for the user to access the first electronic file via the firstapplication such that: (i) the first portion of the first electronicfile is available to the user based on the first security requirementassociated with the first portion and the security characteristic, and(ii) the second portion of the first electronic file is not available tothe user based on a second security requirement associated with thesecond portion and the security characteristic.
 2. The method of claim1, wherein the electronic file is associated with at least one of: (i) aword processing document, (ii) a spreadsheet file, (iii) an image file,(iv) an audio file, (v) a video file, (vi) an electronic mail file,(vii) streaming information, (viii) a text file, (ix) an XML file, or(x) a source code file.
 3. The method of claim 1, wherein the securitycharacteristic is associated with at least one of: (i) a useridentifier, (ii) a user credential, (iii) a user role within anorganization, (iv) a user age, (v) social network information, (vi) auser device, (vii) user preferences, or (viii) past behavioral patterns.4. The method of claim 1, wherein said arranging is performed via aplug-in component of the first application.
 5. The method of claim 1,the user's access to the first portion of the first electronic file isassociated with at least one of: (i) viewing the first portion, (ii)deleting the first portion, (iii) changing the first portion, (iv)altering the first security requirement, or (v) creating a new portion.6. The method of claim 1, wherein automatically detecting a type of dataadded to the first portion comprises monitoring characteristics of thefirst portion and wherein the electronic file security managementplatform automatically assigns the first security requirement to thefirst portion based on content detected in the first portion.
 7. Themethod of claim 6, further comprising: storing automatically assignedsecurity requirements in a metadata repository.
 8. The method of claim7, further comprising: generating an automatic notification when contentis detected that conflicts with the first security requirement.
 9. Themethod of claim 7, further comprising: automatically verifying a finalversion of an electronic file and assigning security requirements toportions of the final version in accordance with information in themetadata repository.
 10. The method of claim 1, wherein the electronicfile security management platform automatically assigns the firstsecurity requirement to the first portion based on a creator of thefirst portion.
 11. The method of claim 1, wherein the first and secondsecurity requirements are stored as metadata in the encrypted version ofthe first electronic file.
 12. The method of claim 1, furthercomprising: allowing the user to change the first portion of the firstelectronic file; re-encrypting the first electronic file to create are-encrypted version of the first electronic file; and replacing theencrypted version of the first electronic file with the re-encryptedversion.
 13. The method of claim 1, further comprising: receiving, atthe electronic file security management platform, a request from adifferent user to access the first electronic file; determining adifferent security characteristic associated with the different user;decrypting the encrypted version of the first electronic file inaccordance with the different security characteristic; and arranging,via the electronic file security management platform, for the differentuser to access the first electronic file via the first application suchthat both the first and second portions of the first electronic file areavailable to the user based on the first and second securityrequirements and the different security characteristic.
 14. Anon-transitory, computer-readable medium storing program code executableby a computer processor to perform a method facilitating access toelectronic files via a plurality of applications, the method comprising:receiving, at an electronic file security management platform, a requestfrom a user to access a first electronic file associated with a firstapplication, the electronic file comprising a first portion and a secondportion; automatically determining, via a processor device, a firstsecurity requirement associated with the first portion, the firstsecurity requirement stored as in an encrypted version of the firstelectronic file, the determining of the first security requirementcomprising: automatically detecting additional data of a particular typethat has been added to the first portion of the electronic file,automatically determining, in response to the detection, a category ofusers that can view the added data, and automatically limiting access ofthe first portion of the electronic file to the category of users basedupon the added content detected in the first portion; determining asecurity characteristic associated with the user; decrypting theencrypted version of the first electronic file in accordance with thesecurity characteristic and the security requirement associated with thefirst portion; and arranging, via the electronic file securitymanagement platform, for the user to access the first electronic filevia the first application such that: (i) the first portion of the firstelectronic file is available to the user based on the first securityrequirement associated with the first portion and the securitycharacteristic, and (ii) the second portion of the first electronic fileis not available to the user based on a second security requirementassociated with the second portion and the security characteristic. 15.The medium of claim 14, wherein the electronic file is associated withat least one of: (i) a word processing document, (ii) a spreadsheetfile, (iii) an image file, (iv) an audio file, (v) a video file, (vi) anelectronic mail file, (vii) streaming information, (viii) a text file,(ix) an XML file, or (x) a source code file.
 16. The medium of claim 14,wherein the security characteristic is associated with at least one of:(i) a user identifier, (ii) a user credential, (iii) a user role withinan organization, (iv) a user age, (v) social network information, (vi) auser device, (vii) user preferences, or (viii) past behavioral patterns.17. The medium of claim 14, wherein said arranging is performed via aplug-in component of the first application.
 18. The medium of claim 14,the user's access to the first portion of the first electronic file isassociated with at least one of: (i) viewing the first portion, (ii)deleting the first portion, (iii) changing the first portion, (iv)altering the first security requirement, or (v) creating a new portion.19. The medium of claim 14, wherein automatically detecting a type ofdata added to the first portion comprises monitoring characteristics ofthe first portion and wherein the electronic file security managementplatform automatically assigns the first security requirement to thefirst portion based on content detected in the first portion.
 20. Themedium of claim 14, wherein the electronic file security managementplatform automatically assigns the first security requirement to thefirst portion based on a creator of the first portion.
 21. The medium ofclaim 14, wherein the first and second security requirements are storedas metadata in the encrypted version of the first electronic file.
 22. Asystem, comprising: a file repository storing a plurality of electronicfiles, including an encrypted version of a first electronic fileassociated with a first application, wherein the encrypted version ofthe first electronic file contains metadata indicating a first securityrequirement associated with a first portion of the first electronic fileand a second security requirement associated with a second portion ofthe first electronic file, the first security requirement determined byautomatically detecting additional data of a particular type that hasbeen added to the first portion of the electronic file, automaticallydetermining, in response to the detection, a category of users that canview the added data, and automatically limiting access of the firstportion of the electronic file to the category of users based upon theadded content detected in the first portion; and an electronic filesecurity management platform, comprising a processor, to (i) receive arequest from a user to access a first electronic file associated with afirst application, (ii) determine, via the processor, a securitycharacteristic associated with the user, (iii) decrypting the encryptedversion of the first electronic file in accordance with the securitycharacteristic, and (iv) arrange for the user to access the firstelectronic file via the first application such that: a first portion ofthe first electronic file is available to the user based on the firstsecurity requirement and the security characteristic, and a secondportion of the first electronic file is not available to the user basedon the second security requirement associated with the second portionand the security characteristic.
 23. The system of claim 22, wherein theelectronic file is associated with at least one of: (i) a wordprocessing document, (ii) a spreadsheet file, (iii) an image file, (iv)an audio file, (v) a video file, (vi) an electronic mail file, (vii)streaming information, (viii) a text file, (ix) an XML file, or (x) asource code file.
 24. The system of claim 22, wherein the securitycharacteristic is associated with at least one of: (i) a useridentifier, (ii) a user credential, (iii) a user role within anorganization, (iv) a user age, (v) social network information, (vi) auser device, (vii) user preferences, or (viii) past behavioral patterns.25. The system of claim 22, wherein said arranging is performed via aplug-in component of the first application.
 26. The system of claim 22,the user's access to the first portion of the first electronic file isassociated with at least one of: (i) viewing the first portion, (ii)deleting the first portion, (iii) changing the first portion, (iv)altering the first security requirement, or (v) creating a new portion.